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INTERPROCESSOR COMMUNICATION PROTOCOL PROVIDING 
INTELLIGENT TARGETING OF NODES 



TECHNICAL FIELD 

This invention relates in general to the field of electronics, and more 
specifically to an InterProcessor Communication (IPC) protocol/network providing 
intelligent targeting of nodes. 

BACKGROUND 

Most electronic systems include a number of networked elements 
(components) such as hardware and software that form the system. In most systems 
there is a layer responsible for communication between the different components that 
form a networked element as well as between the different networked elements 
themselves. This layer is typically referred to as the InterProcessor Communication 
(IPC) layer. 

Several protocols have been introduced in the last few years to deal with 
interprocessor communications. One example of an IPC product is PCI AGP 
Controller (PAC) that integrates a Host-to-PCI bridge, Dynamic Random Access 
Memory (DRAM) controller and data path and an Accelerated Graphics Port (AGP) 
interface. Another example of an IPC product is the OMAP™ platforms. Neither of 
these platforms provide much if any support above the hardware level and provide 
little design flexibility at the lower level component or channel levels (physical layer). 

The PAC platforms for example, are closed architectures and are embedded 
into the Operating System's TAPI layer, with the IPC code not being accessible to 
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developers. Therefore, these platforms do not extend to the component levels and 
they also do not allow for dynamic assignment of IPC resources, hardware support 
capabilities, or multi-node routing, etc. as well as not allowing for the dynamic 
assignment of the IPC resources. With the need for lower power consumption and 
less system latencies, a need exists in the art for an IPC network that can provide for 
intelligent targeting of IPC nodes so that there is less wasted time and less power 
consumption when looking for a processor in the IPC system that can provide a 
needed service. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The features of the present invention, which are believed to be novel, are set 
forth with particularity in the appended claims. The invention may best be understood 
by reference to the following description, taken in conjunction with the accompanying 
drawings, in the several figures of which like reference numerals identify like 

1 5 elements, and in which: 

FIG. 1 shows a diagram of an IPC network in accordance with an embodiment 

of the invention. 

FIG. 2 shows an IPC stack in accordance with an embodiment of the 
invention. 

20 FIG. 3 shows an IPC component IPC assignment in accordance with an 

embodiment of the invention. 

FIG. 4 shows the main IPC tables in accordance with an embodiment of the 

invention. 
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FIG. 5 shows a diagram showing channel allocation in accordance with an 

embodiment of the invention. 

FIG. 6 shows a diagram highlighting the steps involved during an IPC client 
initialization routine in accordance with an embodiment of the invention. 

FIG. 7 shows another diagram highlighting the steps involved during an IPC 
client initialization in accordance with an embodiment of the invention. 

FIG. 8 shows a diagram highlighting the first level of IPC encapsulation in 
accordance with an embodiment of the invention. 

FIG. 9 shows a diagram highlighting the steps taken during IPC component 
initialization in accordance with an embodiment of the invention. 

FIG. 10 shows a chart highlighting the steps taken during component 
initialization in accordance with an embodiment of the invention. 

FIG. 1 1 shows the transfer of IPC data between an IPC client and an IPC 
server in accordance with an embodiment of the invention. 

FIG. 12 shows a diagram of an IPC data header in accordance with an 

embodiment of the invention. 

FIG. 13 shows a diagram of the steps taken during an IPC data request in 
accordance with an embodiment of the invention. 

FIG. 14 shows an IPC network in accordance with an embodiment of the 

2 0 invention. 

FIG. 15 shows an electronic device such as a radio communication device in 
accordance with an embodiment of the invention. 

Figs. 16 and 17 show diagrams of outbound streaming in accordance with an 

embodiment of the invention. 
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FIG. 18 shows a diagram of inbound streaming in accordance with an 
embodiment of the invention. 

FIG. 19 shows a diagram of an IPC network in accordance with an 

embodiment of the invention. 

FIG. 20 shows a flowchart highlighting some of the steps taken in performing 
intelligent targeting of nodes in accordance with an embodiment of the invention. 

FIG. 21 shows an IPC network in accordance with an embodiment of the 
invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

While the specification concludes with claims defining the features of the 
invention that are regarded as novel, it is believed that the invention will be better 
understood from a consideration of the following description in conjunction with the 

15 drawing figures. 

The IPC of the present invention provides the support needed for different 
processors operating in a system to communicate with each other. For example, in a 
dual processor (or multi-processor) radio architecture for use in a radio 
communication device that includes an Application Processor (AP) and a Baseband 

20 Processor (BP), the IPC provides the support needed for the processors to 
communicate with each other in an efficient manner. The IPC provides this support 
without imposing any constrains on the design of the AP or BP. 

The IPC allows any processor that adopts the IPC as its inter-processor 
communication stack to co-exist together and operate as if the two were actually 
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running on the same processor core sharing a common operating system and memory. 
With the use of multiple processors in communication devices becoming the norm, 
the IPC of the present invention provides for reliable communications between the 

different processors. 

The IPC hardware provides the physical connection that ties together the 
different processors to the IPC network. Data packets are preferably transported 
between the different hosts asynchronously in one embodiment of the invention. 
Processors that are connected to the IPC network have their physical and logical 
addresses statistically or dynamically assigned (e.g., IPC addresses). Also, since data 
packets can flow in any direction within the IPC network in one embodiment of the 
invention, they need to carry a destination address of the processor that they are trying 
to reach. Packets are also preferably checked for errors using conventional Cyclic 
Redundancy Check (CRC) techniques. Although the network activities of the IPC 
network of the present invention may have some similarities to those found on an 
internet network that uses IP transport layers such as a Transmission Control 
Protocol/Internet Protocol (TCP/IP) network, the IPC of the present invention is not 
divided into smaller networks with gateways as in a TCP/IP network. 

Referring now to FIG. 1, there is shown an IPC network 100 in accordance 
with an embodiment of the invention. The IPC network 100 includes a plurality of 
IPC clients 102-106, and an IPC server 108 coupled to the IPC clients 102-106 using 
different IPC physical links such as shared memory 110, Universal Asynchronous 
Receiver/Transmitter (UART) 112 and Universal Serial Bus (USB) 114 as some 
illustrative examples. It should be noted that with the IPC of the present invention, an 
IPC client 102-106 can negotiate with the current IPC server 108 to switch roles. If 
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an IPC client 102-106 negotiates to become the IPC server and becomes the new IPC 
server, all of the remaining IPC clients are instructed to change the IP address of the 
server given the change in the IPC server. 

In FIG. 2, there is shown an IPC stack 200 of an IPC server 108 (or IPC clients 
102-108) in accordance with an embodiment the present invention. The IPC stack 
200 is designed to be integrated under an Operating System (OS) and to provide 
support for the inter-processor communication needs of component traffic. The IPC 
stack is composed of the following 3 main layers: 

(1) . IPC Presentation Manager (202) - this layer is used to translate 
different data types between different system components (e.g., software threads). 

(2) . IPC Session Manager (204) - this layer is a central repository for all 
incoming/outgoing IPC traffic between the IPC stack and all of the system 
components. The IPC session manager 204 has several functions: assignment of 
component IDs for participating IPC components; deciding if the IPC data needs to be 
encapsulated; routing of IPC data, termination of IPC traffic; place holder for IPC 
processors; providing IPC addresses, assigning and authenticating IPC clients, etc. 

IPC Transport Layer (208) - located within the IPC session manager 
(layer) 204, the IPC transport layer 208 provides a very basic cyclic redundancy check 
for the purpose of transporting the IPC data between the different processors. In 
addition, the IPC transport layer 208 is responsible for routing IPC messages to their 
final destinations on the IPC network 100. The routing function of the transport layer 

is enabled only on IPC servers. 

IPC Router Block (210) - transports the IPC data to a destination 
component (not shown). Incoming IPC messages carry among other things, the 
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originator component ID, the IPC message opcodes such as Audio and Modem. Note 
that in accordance with an embodiment of the invention, a unique opcode is assigned 
to each component/software thread (see for example 502 in FIG. 5), such as Audio 
and Modem that is coupled to the IPC network. The IPC session manager 204 relies 
on the router block 210 to send the IPC data to the right component(s). 

(3). Device Interface Layer (206) - is responsible for managing the IPC 
physical-to-logical IPC channels. Its main function is to abstract the IPC hardware 
completely so that the stack IPC becomes hardware independent. The device interface 
layer 206 manages the physical bandwidth of the IPC link underneath to support all of 
the IPC logical channels. In the incoming path, the device interface layer 206 picks 
up data from different physical channels 1 10-1 14 and passes them up to the rest of the 
IPC stack. On the outgoing path, the device interface layer 206 manages the data 
loading of the IPC logical channels by sending them onto the appropriate physical 
channels. The device interface layer 206 also handles concatenating IPC packets 
belonging to the same IPC channel before sending them to the IPC hardware. 
Channel requirements are pre-negotiated between the IPC session manager 204 and 
the IPC device interface layer 206. The device interface layer 206 provides for 
hardware ports which in turn provide a device interface to an IPC client 102-106. 

Referring to FIG. 3 there is shown an IPC component ID assignment routine. 
Any new component wishing to participate in an IPC communication must do so by 
first requesting an IPC Identification Number (ID) in step 302 from its IPC session 
manager (e.g., like session manager 204). The local session manager (e.g., session 
manager located in client that the component is coupled to) will then alert the IPC 
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server's session manager of the new IPC components and a component ID assignment 
will be provided in step 304. In accordance with an embodiment of the invention, the 
component IDs are dynamic and can be reassigned by the session manager (e.g., the 
server's session manager). The main IPC server location will most likely be on the 
main AP. Each IPC node will preferably have a unique IPC node ID and the session 
manager will keep in its database the following information for each participating IPC 
node: 

IPC Node Type: For example, a particular BP or AP, a Wireless 

Local Area Network (WLAN) AP, etc. 

IPC address: The IPC address of the IPC node. 

Data Type: The data type of the IPC node. 

Opcode list: This is a list of all the IPC message opcodes that the 

components have subscribed to. 

Component IDs: List of all the component IDs. 

Referring now to FIG. 4, there is shown an IPC stack along with all of the 
main IPC tables. The Dynamic routing table 402 includes the Node Type (processor 
type), IPC address/Port # information, Data Type and Subscription list. The 
Subscription list includes a pointer the list of all IPC supported message op-codes on a 
particular node. The component routing table 404 includes the information linking the 
Opcode information and all of the components subscribed to each particular Opcode. 
Finally, the Channel Resource table 406 includes a linking of each Channel ID with a 
list of physical channel IDs. 
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In FIG. 5, there is shown a block diagram of how the IPC stack in accordance 
with an embodiment of the invention, provides an IPC channel for a component such 
as a software thread (e.g., Audio, etc.). Component 502 first requests an IPC channel 
in step 504. The session manager shown in FIG. 5, negotiates the component's 
request with the Device Layer in step 506 using a defined API. The Device layer 
(Device Interface) then requests hardware resources, such as a data channel 508. The 
session manager shown in FIG. 5 in response to the request, grants an IPC channel to 
the requester in step 510. The component 502 next sends its data on the assigned 
channel 508. The device layer then forwards the data to the IPC network. The 
mapping of the logical to physical channel IDs is the function of the IPC device 
interface. 

Referring now to FIG. 6, the first step in IPC client initialization is sending a 
registration request (step 606) between the IPC client 602 and the IPC server 604. 
The IPC server 604 then authenticates the request with the IPC client 602 in step 608. 
This is followed by sending an IPC address to the IPC client and completing the 
registration in step 610. The IPC client's session manger sends a copy of its dynamic 
routing table to the IPC server in step 612. 

More detailed steps taken during the IPC client initialization process are 
shown in FIG. 7. The client session manager (shown in table as Session (client)) 
sends a configuration request to the IPC server's session manager (shown in table as 
Session (Server)) in step 702. In step 704, authentication is requested by the IPC 
server's session manager. Authentication between the IPC client and IPC server is 
then carried out in step 706. 
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The parameters in the configuration request include the node type and the data 
type. The session server in response to the configuration request in step 702 assigns 
the requestor an IPC address. It also sets up a dynamic routing table for the requestor 
if one does not exist. It then sends the requestor a configuration indication as in step 
5 708. The configuration indication parameters include the IPC address of the server 
and the newly assigned IPC address of the client. 

In response to receiving the configuration indication, components attached to 
the session client can request control/data from the client's session manager. The 
Session client then sends a configuration indication confirm message to the session 

10 server in step 710. The "configuration indication confirm" message has no 
parameters, upon receiving the configuration indication confirm message in step 710, 
the session server can initiate IPC streams to the newly configured session client. The 
session server then sends configuration update messages to the session clients in steps 
712 and 714. This causes the both session clients shown in FIG. 7 to update their 

15 respective dynamic routing tables (not shown) and send a configuration update 
confirm message to the session server in steps 716 and 718. Upon receiving the 
configuration update confirm messages, the session server makes sure all of the IPC 
participants have been updated. 

When a packet is received by an IPC session manager, it comes in the form of 

2 0 data that includes the source component ID, the destination ID, a channel ID and the 
type of BP or AP. The IPC session manager will add the destination component ID in 
the event that the destination ID is not inserted. The IPC session manager will also 
insert an IPC address. It is the IPC session manager that discovers the destination ID 
based on the message opcode received. The destination ID is based on a lookup table. 
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This lookup table is updated dynamically each time a component subscribes to a new 
IPC message opcode (e.g., an audio component subscribes to audio messages by 
sending a request to the IPC session manager). 

In FIG. 8 there is shown a sequence of events during a general destination ID 
discovery sequence between a component and its IPC session manager in accordance 
with an embodiment of the invention. In step 802, the component sends its source ID 
(but no destination ID), the type of the destination BP or AP and the IPC data which 
includes a header and data. In step 804, the IPC session manager looks at the IPC 
data header opcode and the type of destination BP or AP, in order to lookup the 
corresponding dynamic routing table and find the correct destination address. In step 
806, the IPC session manager inserts the IPC address of the component and sends it 
down to the device layer. 

In FIG. 9, typical steps taken during an IPC component initialization are 
shown. Once the BP has been configured by the IPC server shown in FIG. 9, it allows 
components such as component 902 to subscribe to different services. Components 
will subscribe themselves to functions such as Audio, Video, etc. in step 904. The 
component subscription information is then sent to the IPC session manager for 
component ID creations (if an ID is not assigned yet) and creation or updating of the 
dynamic routing table for a particular IPC address (step 906). In step 908, the session 
manager updates the IPC server with the information from step 906. A confirmation 
of the dynamic routing table is sent in step 912 by the IPC server to the IPC client. 
Once the server is alerted, new dynamic routing table updates are broadcast to all 
participating processors in step 910. 
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The same component initialization process is shown between a component 
(client) 1002, a session (client) also known as a client session manager 1004 and the 
session (server) also known as the server session manager 1006 in FIG. 10. A 
component configuration request in step 1008 is sent by the component (client) 1002. 
In response to the request, the client session manager 1004 negotiates a logical 
channel with its device layer (not shown). The client session manager 1004 also 
assigns a component ID and adds the new opcode list to its dynamic routing table (not 
shown). In step 1010, the client session manager 1004 sends a configuration reply 
which includes the component ID and the channel ID as parameters. In response to 
the configuration reply, the component (client) 1002 receives its ID and channel ID 
from the client's session manager 1004. 

Once the client session manager 1004 replies in step 1010 to the configuration 
request in step 1008, the client session manager 1004 sends a configuration update 
request in step 1012 to the session server 1006. The parameters for the configuration 
update request are any new changes that have been made in the dynamic routing table. 
The session manager updates the dynamic routing table for that IPC address. The 
server session manager 1006 in step 1016 then sends all the IPC clients a 
configuration update, while it sends the IPC client a configuration update indication in 
step 1014. The server's session manager 1006 makes sure the IPC server has updated 
its routing table with the changes that were sent. 

In the configuration update message of step 1016 which includes the dynamic 
routing tables as a parameter(s), the session server 1006 updates the dynamic routing 
tables and sends a configuration update confirm message in step 1018. The session 
server 1006 then makes sure all of the IPC participants have been updated. 
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The IPC session manager determines the routing path of incoming and 
outgoing IPC packets. The route of an outgoing packet is determined by the 
component's IPC address. If the destination address is found to be that of a local 
processor, a mapping of the IPC to the Operating System (OS) is carried out within 
5 the session manager. If the destination address is found to be for a local IPC client, 
the packet is sent to the IPC stack for further processing (e.g., encapsulation). Note 
that if the destination component is located on the same processor as the component 
sending the IPC packet, no encapsulation is required and the packet gets passed over 
through the normal OS message calling (e.g., Microsoft Message Queue, etc.). In this 

10 way components do not have to worry about modifying their message input schemes. 
They only need to change their message posting methodologies from an OS specific 
design to an IPC call instead. 

For incoming packets, if the destination address of the message is not equal to 
the IPC server's, the incoming packets gets routed to the proper IPC client. The 

15 routing of incoming packets is handled by the session manager of the IPC server. 
Otherwise, the message is forwarded to the right component or components depending 
on whether or not the component destination ID is set to a valid component ID or to 
OXFF. 

The IPC router block transports the IPC data to the destination component. 
2 0 Incoming IPC messages carry among other things, the originator component ID and 
the IPC message opcodes such as those for Audio, Modem, etc. The IPC session 
manager relies on its component routing table to send the IPC data to the right 
component(s). Both the dynamic routing table and the component routing table are 
updated by the IPC server/client. 
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During power-up, each component must register itself with its session 
manager to obtain an IPC component ID. In addition, it must also subscribe to 
incoming IPC messages such as Audio, Modem, etc. This information is stored in the 
component routing table for use by the IPC session manager. 
5 When a component 1102, as shown in FIG. 11, sends its data request to the 

IPC session manager as in step 1104, a check is made on the destination IPC node 
(e.g., the BP). If the IPC node does not support the IPC message opcode, an error 
reply is returned to the component 1102. In addition to the error reply, the IPC 
session manager returns an update of all the IPC nodes that are capable of receiving 

1 0 that particular opcode. It is up to the component to decide to which of the IPC node(s) 
it will redirect the message. The IPC session manager 1106 will proceed to 
encapsulate the data with the IPC header information before the data is sent on the 
IPC network if the session manager determines that the destination component is 
located in the IPC network but not in the local processor. 

15 In FIG. 12, there is shown an IPC data header 1202 in accordance with an 

embodiment of the invention. The header includes the source and destination IPC 
addresses, source port, destination port provided by the IPC router, the Length and 
checksum information provided by the IPC transport and the source IPC component 
and Destination IPC component provided by the session manager. The Message 

2 0 opcode, message length and IPC data are provided by the component 1204. 

A typical IPC data request in accordance with an embodiment of the invention 
is shown in FIG. 13. In step 1302, the component sends an update request. The 
component update parameters preferably include the node type and opcode. The 
component searches for Node types that support its destination opcode. If the Node 
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type is equal to OxFF, the session manager proceeds to send the component 
information to all the node tables for all IPC participants. If the opcode field is equal 
to OxFF, the session manager proceeds to send the component the opcode list 
belonging to the specified Node type. On the other hand, if the opcode has a specific 
5 value, the session manager proceeds to send the component a true or false value 
corresponding to whether the Node type supports or does not support that particular 
opcode. 

In step 1304, the component update indication is sent to the component. If the 
node type is equal to OxFF, the node tables are returned to the component. If the 

10 opcode field is equal to OxFF, the list of opcodes is returned to the component. 
However, if the opcode is a specific value, a true or false message is returned. In step 
1306, a component data request is made. The parameters for the component data 
request include the node type, the IPC message opcode, the IPC message data, the 
channel ID and the component ID. In a component data request, the session manager 

15 checks the node type to determine whether the opcode is supported. If the node type 
does not support the opcode, a component update indication is sent in step 1308. If 
however, the node type supports the opcode, a data request is sent to the device layer 
in step 1310. The data request parameters include the IPC message, the channel ID 
and the IPC header. 

2 0 The device layer schedules to send the data request message based on the 

channel ID. The device layer selects the IPC hardware based on the port # header 
information. Once the data is committed, a data confirm message is sent to the 
session manager in 1312. In step 1314, the session manager proceeds to send a 
component data confirm message to the component. The component can wait for the 
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confirmation before sending more IPC messages. Once a data confirm is received, the 
component can proceed to send the next IPC message. 

In step 1316, the device layer sends a data indication message including IPC 
message data and an IPC header. The session manager checks the destination IPC 
header of the message, and if different from the local IPC address, the session 
manager sends (routes) the message to the right IPC node. In step 1310, the session 
manager sends a data request to the device layer with a reserved channel ID. The 
session manager checks the destination component ID, and if it is equal to OxFF, 
routes the message to all the components subscribed to that opcode. In step 1318, the 
session manager sends a component data indication message and the component 
receives the IPC data. 

The IPC stack uses a reserved control channel for communication purposes 
between all participating IPC nodes. On power-up, the IPC server's session manager 
uses this link to broadcast messages to IPC clients and vice versa. During normal 
operations, this control channel is used to carry control information between all APs 
and BPs. 

In FIG. 14, there is shown the control channels 1402-1406 located between the 
IPC stacks and the IPC hardware. Control channel information 1408 is also 
transmitted along with data packets 1410 when sending data between different IPC 
hardware. An IPC client broadcasts its configuration request initially on the IPC 
control channel. The IPC server receives the broadcast and responds with an IPC 
address for that client. This IPC address becomes associated with the dynamic routing 
table for that particular processor (AP or BP). 
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IPC APPLICATION PROGRAM INTERFACES (APIs) 

Below are listed some of the APIs for the IPC protocol of the present 
invention. 

1). Component Interface to the IPC session manager: 

5 CreateComponentlnstO 

Creates a component database in the IPC session manager. Information such as 
component data types (Big Endian vs. little Endian) and subscription to 
message opcodes are used in the dynamic data routing table belonging to an 
IPC address. 

10 

OpenChannelKeepO 

Open an IPC channel and if one is available, a ChannelGrant() is issued. The 
channel is reserved until a CloseChannelQ is issued. Components send QoS 
requests to the IPC session Manager. The IPC channel assigns a component ID 
15 if one is not yet assigned (e.g. Channel Grant()). 

OpenChannelO 

Open an IPC channel and if one is available, a ChannelGrant() is issued. The 
parameters are the same used for the OpenChannelKeepO primitive. 

2 0 

OpenChannelWThruO 

Open an IPC channel and if one is available, a ChannelGrant() is issued. This 
is a request for a write thru channel signifying that encapsulation be turned off 
on this channel (e.g. Non UDP AT commands). 

25 

CloseChannelO 

Request that an IPC channel be closed. The Component no longer needs the 
channel. The resources are then freed. 

3 0 ChannelGrantO 

A channel is granted to the requestor. The Channel IDs are assigned by the 
IPC session manager if one is not yet assigned. 

ChannelErrorO 

3 5 A channel error has occurred. The channel is closed and the requestor is 

notified. 

ChannelDatalndicationO 

The requestor is alerted that data on a channel is to be delivered. This message 

4 0 is sent by the IPC presentation manager to the target component. This also 

includes control channel data. 
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DataChannelRequestO 

The requestor wants to send data on an opened channel. This also includes 
control channel data. 

5 ChannelCloseO 

Request that an IPC channel be closed. A channel inactivity timer expired and 
the Channel associated with the timeout is closed. This could also be due to 
channel error. 



2). IPC session manager to/from IPC device interface 
OpenChannelQ 

Open a logical IPC channel and if one is available, a ChannelGrant() is issued. 
The IPC session manager sends channel priority requests to the IPC device 
interface manager. 

CloseChannelO 

Request that an IPC logical channel be closed. A component decides that it no 
longer requires the channel. 

ChannelGrantO 

A logical channel is granted to the requestor. 
ChannelErrorO 

A channel error has occurred (e.g. CRC failure on incoming data or physical 
channel failure). 

ChannelDatalndicationO 

The requestor is alerted that data on a channel is to be delivered. 
DataChannelRequestO 

The requestor wants to send data on the logical channel. 
ChannelCloseO 

Request that an IPC channel be closed. A channel inactivity timer expired and 
the Channel associated with the timeout is closed. This could also be due to 
channel error. 



3) . IPC session manager to IPC presentation manager 

ChannelDatalndicationO 

4 0 The requestor is alerted that data on a channel is to be delivered. The 

information is to be forwarded to the target component with the correct data 
format. 

4) . IPC Hardware/IPC Stack Interface 
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OpenChannelO 

Open a physical IPC channel and if one is available, a ChannelGrant() is 
issued. The IPC session manager sends channel priority requests to the IPC 
5 Hardware. 

CloseChannelO 

Request that an IPC physical channel be closed. The component no longer 
requires the channel. 

10 

ChannelGrantO 

A physical channel is granted to the requestor. 
ChannelErrorO 

15 A channel error has occurred (e.g. CRC failure on incoming data or physical 

channel failure). 

ChannelDatalndicationO 

The requestor is alerted that data on a channel is to be delivered. 

20 

DataChannelRequestO 

The requestor wants to send data on the physical channel. 
ChannelCloseO 

2 5 Request that an IPC channel be closed. A channel inactivity timer expired and 

the Channel associated with the timeout is closed. This could also be due to 
channel error. 



3 0 In FIG. 15, there is shown a block diagram of an electronic device such as a 

radio communication device (e.g., cellular telephone, etc.) 1500 having a baseband 
processor (BP) 1502 and an application processor (AP) 1504 communicating with 
each other using an IPC network. The IPC protocol of the present invention provides 
for communications between multiple processors in a system such as a 

3 5 communication device. The IPC allows for a Mobile Application (MA) client (e.g., 
iDEN™ WLAN) to register with a MA server such as a Personal Communication 
System (PCS) application, and will provide the means for the two MAs to 
communicate freely without any limitations on what software architectures, operating 
systems, hardware, etc. each depend on within its own MA. 
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The IPC protocol allows for the dynamic addition of any IPC conforming MA 
into the IPC link for communication. Thus, an IPC network is formed without any 
compile time dependencies, or any other software assumptions. The IPC of the 
present invention presents a standard way for software components to communicate 
5 with the IPC stack and the hardware below the stack is also abstracted such that 
components can choose different links to communicate. 

Referring now to FIG. 16, there is shown three components such as software 
threads, 1602, 1604 and 1606, and how they establish outbound streaming. Software 
thread 1602 for example, sends a request 1612 in for a predetermined QoS 1608 and 

10 submits its opcode subscription list 1610. In return, software thread 1602 is assigned 
a channel ID 1614 and a component ID 1616 in response message 1618. Components 
such as software threads 1602, 1604 and 1606 in accordance with an embodiment of 
the invention are assigned IPC hardware resources depending on their requirements. 
The components 1602, 1604 and 1606 can be dynamically installed or uninstalled 

1 5 depending on the system requirements. 

In FIG. 17, components 1602, 1604 and 1606 send IPC data on their assigned 
channels such as channel 1702 for software thread 1602. The components 1602, 1604 
and 1606 submit their data along with a target IPC node, although components can 
also broadcast their messages to all IPC nodes when no node is specified. The 

2 0 components 1602, 1604 and 1606 do not need to know the destination components 
IDs, nor their associated channels nor their IPC address. Regarding inbound 
streaming, message opcodes identify components. For example, in FIG. 18, 
components 1602, 1604 and 1606 are identified by the message opcodes. Component 
IDs are discovered through the component routing table previously discussed. The 
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IPC session manager routs incoming data to all the components that have subscribed 
to the IPC opcode in the message. 

INTELLIGENT TARGETING OF IPC NODES 

5 In order to provide improved overhead efficiency and power management, an 

IPC protocol/network in accordance with the invention provides for intelligent 
targeting of nodes (any IPC server or client processor, also referred to an MA in a 
radio environment) based on the state of the processors operating within the IPC 
network. For example, when a MA tries to find support for a particular service (e.g., 
10 MP3 decoder, etc.) on the IPC network through the use of intelligent targeting, the 
source application will find a processor or MA that can provide the service in the most 
efficient fashion. This will provide for improved battery life and less latency to the 
MA applications. 

In one embodiment, the requesting or source MA will send to the IPC server's 
15 IPC stack a message with the particular opcode corresponding to the requested 
service, for example a MP3 service. The IPC stack will then check its opcode table to 
determine the requested service and then the IPC stack will check its subscription lists 
to see which MAs/nodes can support the requested service, in this particular example, 
perform MP3 decoding. 
'20 As an illustrative example, if 3 MAs on the IPC network can provide the MP3 

decoding service, but one is in a deep sleep mode, another one is busy performing 
other tasks and does not have the necessary unused processing horsepower to perform 
MP3 decoding, and the third MA can perform the MP3 processing, the IPC stack will 
send a message back to the requesting MA and inform it which MA can perform the 
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MP3 decoding based on the current state of the MAs capable of performing the MP3 
decoding service. 

If the requesting MA does not have a particular need to use a particular MA, it 
will use the MA that the IPC server's IPC stack has recommended. In this fashion, 
the resources on the whole IPC network will be best utilized. Located in the IPC 
server's IPC stack will be a table with the current operational state of each of the 
MA's (nodes) operating in the IPC network. The table will keep track of which of the 
MA's/IPC client's are currently in a sleep mode, or are busy performing other tasks. 
Along with the opcode and subscription lists, the operational state table will let the 
IPC network know the current operating condition of all of the MAs including their 
traffic loads and capabilities and whether or not they are currently in sleep mode. 

In order to provide the necessary information stored in the operational state 
table that is found in the IPC server, if an MA in the IPC network wants to go into a 
sleep mode it will alert the IPC server by sending a control message or API to it that 
lets it know that is will be going into a sleep mode. The MAs will also alert the IPC 
server when they wake up and return to normal operation, so that the usage table can 
be updated. The traffic load information for each of the MAs will also be provided by 
the MAs to the IPC server, for example prior to a MA commencing a task such as 
video decoding, it will send a message to the IPC server informing the IPC server that 
is commencing a task and that a certain amount (e.g., 20%) of its processing 
capabilities are currently being used. Alternatively, nodes can report to the IPC server 
when they have reached a certain computational usage threshold level, for example, 
when they have reached 50% of computational capacity or they can provide their 
usage levels periodically, every few minutes. 
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In order to perform the requirements of the present invention, the IPC server 
such as IPC server 108 shown in FIG. 1, will keep track of the operational condition 
of all of the nodes (IPC clients 102-106) and will use the operational condition 
information along with the dynamic routing table information the IPC server 108 
receives from all of the IPC clients as well as the component routing table to make 
intelligent decisions as to which node is better suited to handle a service request. 

Referring now to FIG. 19, there is shown a flowchart highlighting some of the 
steps taken in accordance with one embodiment of the invention. In step 1902, a 
processor (MA) which is in need of performing a service request, sends a service 
request message to the IPC server (e.g., IPC server 108). The IPC server will compare 
the opcode using its opcode list and determine which service is being requested and 
will look through the subscription list(s) in step 1904 to determine which nodes 
(MAs) can provide the requested service within the IPC network. In step 1906, the 
IPC server will determine from those MA(s) that can provide the requested service 
(e.g., MP3 decode) which is in the best operational state to handle the request. 

The IPC server will then look through its operational state table which is 
frequently updated and determine which MA is in the best condition to handle the 
service request. For example, it could be that out of three MAs that can support the 
requested service, one may be in sleep mode, one may be fully occupied from a 
resource standpoint to handle any further service requests, and one may have enough 
capacity to handle the request. In step 1908, the IPC server sends a message to the 
service requestor informing it which MA will handle the service request. The IPC 
server can also update its operational state table at this time noting that the selected 
MA is performing the service and adjust its operational capabilities accordingly (e.g., 
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note that the MA is using 10% of its computational capability performing the 
requested service). 

In FIG. 20, there is shown an operational state table 2000 such as that which 
can be found in the IPC server's IPC stack. The operational state table will keep track 
5 of all the processors (nodes) 2010 currently on the IPC network and their 
corresponding operational state 2012. As an illustrative example, the operational state 
table 2000 can include in row 2002 information on node 1 and its current operational 
state, in this case, the node 1 processor is in a sleep mode. The operational state from 
the node 1 processor can be sent to the IPC server using IPC control messages. In this 

10 case, the node 1 processor would send a control message to the IPC server letting it 
know it was entering a sleep mode in order for example to conserve power. Row 
2004 shows that node 2 is currently busy and cannot handle any more service 
requests. The busy state can be due to the fact that the node 2 processor is currently 
working on one or more requests and does not have any more available computational 

15 capacity to handle any more requests. The node 2 processor in accordance with an 
embodiment of the invention would send a control message every so often informing 
the IPC server what it current capabilities to handle other service requests are. 

In row 2006, there is shown that the node 3 processor is currently available to 
handle any service requests since it may not be performing any services currently. In 

20 row 2008, the node 4 processor is shown to be 50% available, but that its MP3 decode 
capability is not available (e.g., may be currently being used). 

So if in this particular example the service requestor had asked for an MP3 
decode service, the IPC server would first find all the nodes in the IPC network that 
can handle the MP3 decode service request (e.g., nodes 1-4), then it would search 
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through the operational state table 2000 to determine which node would be best suited 
to handle the request. In this example, node 3 would be in the best condition to 
handle the service request. The IPC server would send a message to the service 
requestor informing it that node 3 will handle its request. 

In an alternative embodiment of the invention, the service requestor can not 
only send a request for a specific service by sending a message with the opcode 
corresponding to the requested service, but can also inform the IPC server that it 
wants a specific node to handle the request. In this particular case, if for example the 
service requestor wanted node 4 to handle the service request, the IPC server could 
keep checking its operational state table until node 4 was found to be available, and at 
that time, assign node 4 to handle the service request. 

In FIG. 21, there is shown a daisy-chained IPC network 2100 in accordance 
with another embodiment of the invention. IPC network 2100 includes an IPC server 
2100 and a plurality of nodes such as clients 1-3 (2102-2106). Client 2 (2104) 
includes a set of daisy-chained sub-clients 2.1 and 2.2 (2108 and 2110). In 
accordance with an embodiment of the invention, since network 2100 has sub-clients, 
the IPC server 2112 can periodically send client 2 (2104) as an example, the current 
operational state table information, such as operational state table 2000. Client 2 
(2104) can store the operational state table information in its memory and use the 
information to assign nodes to service requests made by its sub-clients 2108 and/or 
2110. In this way a service request sent by either sub-client 2108 or sub-client 2110 
can be handled by client 2 (2104) without the need to have the IPC server 2100 make 
the service assignment decision. 
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If client 2 (2104) handles a service request from either sub-client 2108 or 21 10 
and informs it which node to use for the requested service, it must immediately inform 
the IPC server 2100 so that it can update its operational state table and keep the 
operational state information of all the nodes in the network current. "Dropping" the 
5 operational state table information to lower levels of a daisy-chained IPC network 
allows for service request decisions to be made quicker, since the service request does 
not have to travel multiple layers. The operational state table information can be sent 
to select ones of the clients on a predetermined basis, such as when an update to the 
operational table in the IPC server 21 12 is updated (e.g., one of the nodes (clients) has 
10 gone to sleep and informed the IPC server 2112) or after a predetermined period of 
time has elapsed. 

While the preferred embodiments of the invention have been illustrated and 
described, it will be clear that the invention is not so limited. Numerous 
modifications, changes, variations, substitutions and equivalents will occur to those 
15 skilled in the art without departing from the present invention as defined by the 
appended claims. 

What is claimed is: 
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